@yfukai This PR is related to #228; there are a couple of points that need to be addressed.
The SQLGraph code becomes a bit more complex, and it doesn't bring much joy. I need to consider whether there's a better alternative and if this truly resolves #228

Codecov Report

❌ Patch coverage is 66.66667% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.48%. Comparing base (b0a7ebd) to head (c97cd01).

@@            Coverage Diff             @@
##             main     #234      +/-   ##
==========================================
- Coverage   88.50%   88.48%   -0.02%     
==========================================
  Files          55       55              
  Lines        3959     3953       -6     
  Branches      696      696              
==========================================
- Hits         3504     3498       -6     
  Misses        273      273              
  Partials      182      182              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Thanks! This makes sense a lot!

• If possible, I might stick to an option to bind the field names to the graph objects themselves rather than having them globally, since one might have graphs with different column names in a single script.
• Maybe we could also update ["z", "y", "x"].

uhm... , ok, if we bind everything to the graph, then every default attr_key must be None and check the graph's default.
Do you see another way of implementing it?

Right, in that sense, the current implementation looks better for me!
(Sorry I changed my mind) I agree with the current implementation (and changing those names can be discouraged except in special cases).
Maybe we could also update ["z", "y", "x"]?

We also need to implement the attr name conversion in functions that read other file formats such as GEFF.

Happy New Year @yfukai ,
I agree with you, I opened these PRs #239, #238
Do they fix your issue?
Any suggestions?

All looks good to me, thanks @JoOkuma! (Btw happy new year!)